Systems and methods for protecting an identity in network communications

ABSTRACT

In some embodiments, a method includes sending a first data unit, received from a source device, to a destination device via a first data unit path. The first data unit path includes (1) a first virtual machine and a second virtual machine that are included in a first network, and (2) a third virtual machine that is included in a second network. Furthermore, the first data unit path includes the first virtual machine, the second virtual machine, and the third virtual machine in a first order. The method includes sending a second data unit, received from the source device, to the destination device via a second data unit path from the source device to the destination device. The second data unit path includes each of the first virtual machine, the second virtual machine, and the third virtual machine in a second order different from the first order.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.17/688,373, filed Mar. 7, 2022, which is a continuation of U.S. patentapplication Ser. No. 17/063,102, filed Oct. 5, 2020, now U.S. Pat. No.11,272,037, which is a continuation of U.S. patent application Ser. No.15/858,435, filed on Dec. 29, 2017, now U.S. Pat. No. 10,798,217, whichis a continuation of U.S. patent application Ser. No. 15/237,271 filedon Aug. 15, 2016, now U.S. Pat. No. 9,860,342, which is a continuationof U.S. application Ser. No. 13/961,379 filed on Aug. 7, 2013, now U.S.Pat. No. 9,417,922, which claims priority to U.S. ProvisionalApplication No. 61/732,664 filed on Dec. 3, 2012, each of which istitled “Systems and Methods for Protecting an Identity in NetworkCommunications,” the contents of each of which is herein incorporated byreference in its entirety.

This application is related to U.S. Pat. No. 8,984,138, issued on Mar.17, 2015 and titled “Systems and Methods for Protecting an Identity inNetwork Communications,” the contents of which is herein incorporated byreference in its entirety.

BACKGROUND

Some embodiments described herein relate to protecting a source identityin network communications.

Known methods of communications within and across networks havingcommercial clouds is typically through routing at the network layerbased on an external internet protocol (IP) address. The network willforward the packets to the requested IP address via the most expedientpath available. This communications method, however, fails to providefor the ability to route via one or more intermediate locations to maskthe source or identity of the communications.

Thus, a need exists for additional routing techniques that provide anautomated ability to control the routing of communications within andacross networks having commercial clouds and networks.

SUMMARY

In some embodiments, a method includes sending a first data unit,received from a source device, to a destination device via a first dataunit path. The first data unit path includes (1) a first virtual machineand a second virtual machine that are included in a first network, and(2) a third virtual machine that is included in a second network.Furthermore, the first data unit path includes the first virtualmachine, the second virtual machine, and the third virtual machine in afirst order. The method includes sending a second data unit, receivedfrom the source device, to the destination device via a second data unitpath from the source device to the destination device. The second dataunit path includes each of the first virtual machine, the second virtualmachine, and the third virtual machine in a second order different fromthe first order.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of an identity-protection system(“system”), according to an embodiment.

FIG. 2 is a schematic diagram of a system, according to an embodiment.

FIG. 3 is a schematic diagram of the system depicted in FIG. 2 ,according to an embodiment.

FIG. 4 is a schematic illustration of an identity-protection system,according to an embodiment.

FIG. 5 is a schematic illustration of an identity-protection system,according to an embodiment.

FIG. 6 is a schematic illustration of an identity-protection system,according to an embodiment.

FIG. 7 is a schematic illustration of an identity-protection system,according to an embodiment.

FIG. 8 is a schematic flow diagram of a system, according to anembodiment.

FIG. 9 is a flow chart illustrating a method of operating anidentity-protection system, according to an embodiment.

DETAILED DESCRIPTION

In some embodiments, an apparatus includes a network layout moduleconfigured to be operatively coupled to a first network that includes afirst virtual machine and a second virtual machine, and that isconfigured to be operatively coupled to a source device and adestination device. The network layout module is configured to beoperatively coupled to a second network, different from the firstnetwork, that includes a third virtual machine and a fourth virtualmachine, and that is configured to be operatively coupled to the sourcedevice and the destination device. The network layout module configuredto define, at a first time, a first data unit path from the sourcedevice to the destination device. The first data unit path includes eachof the first virtual machine, the second virtual machine, the thirdvirtual machine and the fourth virtual machine in a first order. Thenetwork layout module configured define, at a second time after thefirst time, and in response to an event, a second data unit path fromthe source device to the destination device. The second data unit pathincludes each of the first virtual machine, the second virtual machine,the third virtual machine and the fourth virtual machine in a secondorder different from the first order.

In some embodiments, a method includes defining, at a first time, afirst data unit path from a source device to a destination device, thefirst data unit path includes (1) a first virtual machine and a secondvirtual machine that are included in a first network, and (2) a thirdvirtual machine that is included in a second network. The first dataunit path includes the first virtual machine, the second virtualmachine, and the third virtual machine in a first order. The methodincludes modifying, in response to defining the first data unit path, arouting table such that a first data unit sent from the source device tothe destination device, prior to a second time after the first time,follows the first data unit path. The method includes defining, afterthe second time, a second data unit path from the source device to thedestination device. The second data unit path includes each of the firstvirtual machine, the second virtual machine, and the third virtualmachine in a second order different from the first order. The methodincludes modifying, in response to defining the second data unit path,the routing table such that a second data unit sent from the sourcedevice to the destination device, after the second time, follows thesecond data unit path.

In some embodiments, a method includes sending a first data unit,received from a source device, to a destination device via a first dataunit path. The first data unit path includes (1) a first virtual machineand a second virtual machine that are included in a first network, and(2) a third virtual machine that is included in a second network.Furthermore, the first data unit path includes the first virtualmachine, the second virtual machine, and the third virtual machine in afirst order. The method includes sending a second data unit, receivedfrom the source device, to the destination device via a second data unitpath from the source device to the destination device. The second dataunit path includes each of the first virtual machine, the second virtualmachine, and the third virtual machine in a second order different fromthe first order.

Some embodiments provide cloud-based secure virtual private networks(VPNs) and identity-(persona-) protected access to the Internet. Someembodiments provide support for customer migration to the cloud, a rangeof identity management and persona attribution options, secure networkconnectivity, and control of customer information held within commercialcloud providers' databases. Some embodiments can distribute thecommunications activity, data storage, and work dynamically within andacross multiple clouds simultaneously (also collectively referred to asthe network). Some embodiments can also provide a mix of cloudtransport, application location, and data storage options. Someembodiments can be implemented to provide each customer with the abilityto define their own dedicated network(s) within a serviceinfrastructure. In addition, some embodiments can augment themulti-layered security capabilities provided by the commercial cloudproviders with an additional layer of encryption and implementation ofdynamic security policies that prohibit malicious traffic from enteringthe network. With such embodiments, companies can take advantage of allthe benefits of cloud technology while improving the overall resiliency,security and exposure on the Internet.

In one embodiment, user-identity-protected access to the Internet can beprovided using commercial clouds for transport purposes. This embodimentcan provide enhanced capabilities for customer access to the Internetwith a range of identity (persona) management options, geolocationsites, and control of the customer information held within commercialproviders' databases. This embodiment can distribute the communicationsactivity dynamically within and across multiple clouds simultaneouslyand regularly chum the underlying network infrastructure. The dynamictransport of communications for Internet access across multiplecommercial providers make actual user information and originationidentities a very difficult target for hackers, search engineoptimization companies, and other privacy threats.

In some embodiments, users can have the option to connect into anidentity-protection system (system) within a network via a standard IPbrowser session (OSI Layer 3) or though a Virtual Private Networkconnection (OSI Layer 2). Separate identities can be established toacquire infrastructure information (e.g., servers, bandwidth, IPaddresses) from Cloud 1 and Cloud 2 providers. Layer 2 Internet ProtocolSecurity (“IPSEC”) tunnels can be established between the serviceequipment, Cloud 1 infrastructure, and Cloud 2 infrastructure to ensurethat the IP traffic is routed through the network as architected toappropriately protect the user information and origination identities.

To efficiently manage the complexity of establishing and maintaining thenetwork for the service, a virtualization platform, for example, theNicira Network Virtualization Platform (NVP), can be used. NVP is adistributed software suite that defines scalable, fully featured,isolated virtual networks that are completely decoupled and independentfrom the physical network. In some embodiments, other virtualizationplatforms can be used.

Known uses of the Nicira NVP product address the barriers of scalingnetwork infrastructure in data centers to keep pace with the rapidexpansion of cloud technology. Network virtualization decouples networkservices from the underlying physical hardware enabling programmaticcreation of agile, virtual networks to complement the implementation ofstorage and compute virtualization.

Embodiments described herein can use features of the standard Nicira NVPproduct. Such embodiments can establish a logical Layer 2 network acrossthe physical infrastructure (the system, Cloud 1, and Cloud 2) throughuse of NVP, adding Virtual Machines (VMs) connected to the NVP logicalnetworks on a hypervisor at each point of the network. Such embodimentscan develop specific routing instructions for each VM to force thecommunications to follow the intended path.

As discussed above, embodiments of the system can provide identityprotection by using a virtualization platform, for example, the NiciraNetwork Virtualization Platform (NVP). A virtualization platform can bea network control plane that can enable programmatic control ofnetworking capabilities within multi-tenant cloud data centers. Just asserver virtualization can provide flexible control of virtual machines(VMs) running on a pool of server hardware, NVP's networkvirtualization, and other virtualization platforms, can provide acentralized application programming interface (API) to provision andconfigure one or more isolated logical networks on top of a singlephysical network, or more than one physical networks. Logical networkscan decouple VM connectivity and network services from the physicalnetwork, and can give cloud providers the flexibility to place ormigrate VMs anywhere within data centers (or spanning multiple datacenters) while still supporting Layer-2 (L2) connectivity and otherenterprise-class network capabilities.

NVP can provide two network views: (1) the logical network view and (2)the transport network view. The logical network view can describe theconnectivity and network services a VM identifies in the cloud. Thisview can be independent of the underlying physical devices of the datacenter(s) and can be independent of the most expedient path between auser and a network. The transport network view can describe the physicaldevices (the hypervisors that host VMs and the physical network hardwarethat can connect the hypervisor machines) that can handle the actualpacket processing and forwarding that underlie the logical network.

In some embodiments, the logical network view and the transport networkview can exist simultaneously. NVP can act as a network hypervisor thatcan virtualize the transport network view devices to faithfullyimplement the network view. This task can be analogous to how anx86-based hypervisor server can provide each VM with a logical view ofresources (e.g., virtual CPU, memory, and disks) by mapping virtualresources to physical server hardware.

When changes in the logical network view occur, NVP can modify theforwarding state of all relevant Open Virtual Switch (OVS) devices inthe transport network view to reflect the changes. Similarly, whenchanges in the transport network view occur, NVP can update theforwarding rules and state in the transport network view so theconnectivity identified by the VMs remains constant with the logicalnetwork view.

At its core, NVP can expose a centralized API that can be used to definethe logical network view and to control it across the transport networkview. This can make packet forwarding consistent with the logicaldescription.

As described above, the NVP can include a control plane and a dataplane. With regard to the control plane, a controller cluster module canprovide the NVP API (which can be exposed as a web service) used todefine the logical network view and can manage the forwarding state atall transport nodes that the controller cluster module manages that arerunning OVS. The controller cluster module can be a distributed systemthat runs on a set of x86 servers. The data plane can be implemented byaccess-layer switching devices (hypervisor based Open Virtual Switches)that can be managed by the controller cluster module. Known networkhardware (not managed by the cluster) can provide the bandwidth tointerconnect these access-layer devices, enabling them to define networkoverlays that can implement the logical network view.

The virtualization platform can include NVP access switches that cansupport the Open vSwitch (OVS) management interface. OVS managementinterface can be an open protocol that enables control and visibility ofpacket forwarding by a switch. Endpoints connected to OVS-enabled accessswitches can be operatively coupled to a logical network to send andreceive data (e.g., packets, cells, etc). Endpoints can include, forexample, hypervisors and/or gateways. A hypervisor can include a vSwitchthat can be OVS-enabled, which can allow VM endpoints running on thehypervisor to be attached to a logical network. A gateway can attach alogical network to a physical network that is not managed by NVP, e.g.,the Internet. Each gateway can operate as an L2-gateway service thatsend data to a physical L2-segment, or can operate as an L3-gatewayservice mapped to a physical router port.

In the data plane, logical switches can be implemented using differentencapsulation mechanisms, which result in two different types of logicalnetworks: (1) overlay logical networks, and (2) bridged logicalnetworks. Overlay logical networks can use L2-in-L3 tunneling, such thatlogical network topology can be completely decoupled from transportnetwork topology. Bridged logical networks may not use encapsulation,and alternatively, VM traffic on bridged logical networks can be sentdirectly on the physical network, similar to traditional hypervisornetworking. Overlay logical networks can include service nodes. Aservice node can be an OVS-enabled x86 appliance that can be managed bythe controller cluster module and can be used to provide extra packetprocessing capacity to implement logical networks.

The virtualization platform can separate management traffic, e.g.,traffic within the system that instantiates virtual machines, definesand/or updates routing tables, etc, from data traffic. Managementtraffic can be sent and received between OVS devices and the controllercluster module while data traffic can be sent and received directlybetween the OVS devices. The controller cluster module can remainoutside the data path.

The virtualization platform can manage and/or otherwise control the paththat data takes through an identity-protection system (system). Saidanother way, the virtualization platform can define a network layout ofthe system and can therefore control the path data takes through thedefined network layout. An OVS management connection can use SSL forsecurity and can provide the controller cluster module with an interfaceto: (1) view the set of endpoints (VMs or external networks) present ona given OVS device; (2) distribute the logical network forwarding statedown to the OVS devices; and (3) manipulate OVS packet forwarding toimplement the logical network view.

The virtualization platform can be configured such that data trafficto/from the VM or external network endpoints can be handled by OVSdevices (hypervisors, gateways, and service nodes). For example, ahypervisor in one data center can tunnel packets to another hypervisorin a different data center, which can provide L2 connectivity betweentwo VMs that are on the same logical network. For another example, ahypervisor can tunnel a packet to a service node, which can encapsulatethat packet and forward it using a secure VPN tunnel to a gateway in aremote customer premises.

As discussed above the virtualization platform can be used to define oneor more networks included in a system. A network defined by thevirtualization platform can include a transport network view and alogical network view.

The transport network view can include entities that communicate via anAPI and that can inform the controller cluster module about the set ofOVS devices the controller cluster module should manage and how theseOVS devices can communicate to create network overlays. These entitiesshown in the transport network view can includes transport nodes,transport zones, and transport connectors. A transport node can be anyOVS device managed by the controller cluster module, includinghypervisors, gateways and service nodes. A transport zone can be aphysical network that can connect a set of transport nodes. Finally, atransport connector can include the IP address(es) and encapsulationtype(s), define by the controller cluster as attachments to be used bytransport nodes to communicate with each other when implementing overlaylogical networks. For bridged logical networks, transport connectors canindicate the OVS Bridge a hypervisor should use when sending/receivingdecapsulated traffic.

The logical network view can include entities that communicate via anAPI and that can describe the network connectivity identified byendpoints (VMs and external networks) that are plugged into OVS accessswitches. API entities shown in the logical network view include logicalswitches, logical switch ports, logical routers, and attachments. Alogical switch can be an L2 switching overlay implemented using one ofthe supported encapsulation mechanisms (GRE, IPsecGRE, STT, IPsecSTT, orBridge). A logical switch port can be similar to a physical switch port,and can enable the configuration of network services (e.g., securityprofiles, QoS policies) and can expose data for monitoring ortroubleshooting. A logical router, e.g., a virtual L3 router, can beimplemented using one of the supported encapsulation mechanisms (genericrouting encapsulation (GRE), IPsecGRE, spin transfer torque (STT) STT,IPsecSTT, or Bridge). Finally, an attachment can include a “logicalwire,” (e.g., a logical connection), that associates a VM interface (VIFattachment) or external network (L2 gateway attachment, L3 gatewayattachment) with a logical port.

Identity-protection systems described herein can be configured toprotect identities and/or locations (herein “identity/identities”) inand accessing a network. For example, identity-protection systems canprotect an identity of a user and/or an organization, and/or thelocation of data (stored and/or executable). Identity-protection systemscan protect an identity of a private source from a public destination(e.g., a destination on a wide area network such as the internet); canprotect the identities of a private source and/or a private destinationfrom a third party, malicious or otherwise, for example, via a secureprivate network; can protect the location of stored and/or executabledata; and/or can define isolated private networks.

FIG. 1 depicts a schematic diagram of an identity-protection system(“system”) 100 according to an embodiment. Specifically, FIG. 1 depictsa physical view of system 100. System 100 can include the architectureof the network, (e.g., the core level, the aggregation level, the serverlevel, etc) that can provide identity-protected access to a network 170across two commercial clouds as described above. As shown in FIG. 1 ,system 100 can include a control cluster module 102, a service nodemodule 104, a first cloud 110, a second cloud 120, and a customer module130. While shown in FIG. 1 as including two commercial clouds, in otherembodiments, the system can include more or fewer clouds. In someembodiments, control cluster module 102 and/or service module 104 can beinstalled and/or otherwise distributed across one or more computedevices, (e.g., server) in a data center (not shown). In someembodiments, the data center can be the same or different from a datacenter hosting cloud 110 and/or cloud 120. Customer module 130 can beused to manage system 100, for example, manage the specific aspects ofsystem 100 that are associated with a particular customer (user).

As shown in FIG. 1 , cloud 110 can include one or more core modules112A, 112B and one or more aggregation module, 114A-114C. Similarly,cloud 120 can include one or more core modules 122A, 122B and one ormore aggregation module, 124A-124C. While cloud 110 and cloud 120 areshown in FIG. 1 as including two core modules and 3 aggregation moduleseach, in other embodiments either of cloud 110 and/or cloud 120 caninclude more or fewer core and/or aggregation switches.

In some embodiments, a virtualization platform (e.g., NVP) can beinstalled on one or more physical servers 116 within each of cloud 110and cloud 120. In such embodiments, the virtualization platform can beused to instantiate multiple virtual machines 118. In some embodiments,a hypervisor transport node module can be installed to facilitate thedata transport within each cloud. A hypervisor transport node module caninclude a hypervisor and Open vSwitch (“OVS”). In such embodiments, atleast a portion of the multiple virtual machines 118 can be operativelycoupled to the hypervisor to facilitate system 100 communications. Insuch embodiments, routing instructions for system 100 can be installedon each of the multiple virtual machines 118.

In some embodiments, a gateway transport node module (not shown) can beinstalled to provide external connectivity to the Internet. The gatewaytransport node module can be used for routing between the logicalnetworks, and can allow for transport between cloud 110 and/or cloud 120and the Internet. In some embodiments, physical connectivity between thehypervisor transport node module and gateway transport node module canbe via internal IP addresses assigned by cloud 110 and cloud 120.

In some instances, control cluster module 102, also referred to hereinas network layout module, can manage hypervisor transport node modulesand gateway transport node modules. In such instances, when a newhypervisor transport node module and/or a gateway transport node moduleare instantiated, control cluster 102 can be notified to begin managingthe respective module.

Transport node modules (e.g., hypervisor transport node module and/or agateway transport node module) can communicate with each other toimplement logical networks. Transport connectors (not shown in FIG. 1 )can define an encapsulation mechanism and identifiers used for thoseconnections.

FIG. 2 . depicts a schematic diagram of the system 200 according to anembodiment. Specifically, FIG. 2 depicts a logical network view ofsystem 200. System 200 can be similar to and include similar elements assystem 100, and can be used to connect a user 230 to a network 270.System 200 includes a customer module 230, a gateway transport nodemodule 240, a gateway transport node module 250, a logical switch 260,and hypervisor transport node modules 218A, 218B, 228A, 228B. In someembodiments, some hypervisor transport node modules can be instantiatedin a first cloud (not shown in FIG. 2 ) and some hypervisor transportnode modules can be instantiated in a second cloud (not shown in FIG. 2). System 200 can be the network that virtual machines 219A, 219B, 229A,229B identifies. Gateway transport node module 240, gateway transportnode module 250, and hypervisor transport node modules 218A, 218B, 228A,228B communicate with each other to implement the logical network ofsystem 200. In some embodiments, the virtualization platforminstantiates and/or otherwise uses logical switches (e.g. logical switch260) and logical ports (not shown in FIG. 2 ) to represent connectivityand port configuration within the logical view. Virtual machines 219A,219B, 229A, 229B interface with external physical networks via logicalports.

In some embodiments, OVSs can expose/bridge each of virtual machines219A, 219B, 229A, 229B to the hypervisor's physical network interface.In some embodiments, each logical port can include an attachment thatcan act as a source/sink of traffic sent in and out of the logicalnetwork. In some embodiments, virtual machines 219A, 219B, 229A, 229Bcan use a virtual interface (Vif) Attachment such that communicationsacross the entire network are identified as being associated with onelogical switch. This attachment can allow the virtual machines 219A,219B, 229A, 229B to move data from one port to another across thenetwork. Each of virtual machines 219A, 219B, 229A, 229B can includerouting instructions to facilitate communication through the logicalnetwork of system 200. In some embodiments, gateway transport nodemodules 240, 250 can use an L3 gateway attachment that can allow aconnection of a logical switch port to a physical network interfaceexposed via a virtualization platform gateway service (e.g., a nodeconfigured to allow communications between networks using the sameand/or different protocols).

FIG. 3 depicts a schematic diagram of the flow of a packet throughsystem 200 according to an embodiment. Specifically, FIG. 3 depicts alogical-physical view of a packet flowing through system 200. Withreference to FIG. 2 , a user can initiate transmission of data thatincludes a packet at customer module 230. The packet can be sent togateway transport node module 240, and can be switched by an OVSassociated with hypervisor transport node module 218A, using a routingtable, to virtual machine 219A. When the packet first enters the system200, one or more Destination Network Address Translation (DNAT) table(s)301 can be used to map an external, e.g., public IP address to aninternal, e.g., private IP address. In some embodiments, when a packetenters system 200, gateway transport node module 240 can append aninternal IP address to the packet based on its external IP address. Insuch embodiments, the internal IP address can be used, in conjunctionwith the routing table(s), to route the packet through system 200. Next,the packet can be switched by an OVS associated with a hypervisortransport node module 218C, using a routing table, to a physicalinterface 280 between the first cloud and the second cloud. The packetcan then be switched by an OVS associated with hypervisor transport nodemodule 228A, using a routing table, to virtual machine 229A. Next, thepacket can be switched by an OVS associated with a hypervisor transportnode module 228C, using a routing table, to gateway transport nodemodule 250 and out of system 200 to, network 270. Before the packetfirst exits the system 200, one or more Source Network AddressTranslation (SNAT) table(s) 303 can be used to map an internal IPaddress to an external IP address. In some embodiments, when a packetenters system 200, gateway transport module 250 can append the externalIP address to the packet based on its internal IP address. In suchembodiments, the external IP address can be used to route the packet toit final destination outside of system 200.

As described above, the path a packet takes through system 200 can bedynamically changed based on a perceived threat, on a predeterminedschedule, etc. In such instances, the path can travel between any numberof virtual machines across any number of clouds. In some suchembodiments, for example the path can include a first virtual machine ina first cloud, then a first virtual machine in a second cloud, then backto a second virtual machine in the first cloud, then back to a secondvirtual machine in the second cloud. In such embodiments, the routingtables can be updated to ensure proper routing within the network forlegitimate traffic. In some embodiments, because the path changes, anintruder seeking to discern the location of a client website and/orotherwise uncover a source of a packet would be unable to trace thepacket via the original path, because that path may change.

Systems 100 and 200 described above can be used in a variety of ways toprotect identities as described herein. FIGS. 4-7 depict severalembodiments of identity-protection systems that can use systems similarto systems 100, 200 to protect identities. Specifically, systemsdescribed herein can dynamically change a data path between a source anda destination (1) to protect an identity (see, e.g., FIG. 4 ), (2) toprotect the location and/or contents of a storage module (see, e.g.,FIG. 5 ), (3) to define secure virtual private networks (see, e.g., FIG.6 ), and/or (4) to isolate identity-protected networks (see, e.g., FIG.7 ).

FIG. 4 depicts a schematic diagram of a physical layout foridentity-protection system (“system”) 400 according to an embodiment.The system can include network layout module 402, a first cloud 410, anda second cloud 420, and can provide communication with a network 470.Communication between a user 430 and network 470 can include one or moredata paths via first cloud 410 and/or second cloud 420 and via one ormore virtual machines (VM) (not shown) instantiated in first cloud 410and/or first cloud 420. For example, communication between a user ofsystem 400 and the network 470 can routed through a first VM in firstcloud 410, a first VM in second cloud 420, a second VM in first cloud410, a second VM in second cloud 420, and then to network 470.Furthermore, as described herein, the data path between a user 430 andnetwork 470 can dynamically change on a schedule, randomly,pseudo-randomly, upon detection of a threat, by an administrator ofsystem 400, etc. In this manner, an attempt to identify the sourcelocation of a data transmitter along an initial path may be preventedbecause a new path has been established within system 400. In suchembodiments, network layout module 402, can facilitate the updating anddistribution of routing tables within system 400.

FIG. 5 depicts a schematic diagram of a physical layout for anidentity-protection system (“system”) 500 according to an embodiment. Asshown in FIG. 5 , system 500 can be used to define one or more securevirtual private networks 501 between a first entity 530 and a secondentity 532. System 500 can be similar to system 400 and can includesimilar components, for example, system 500 includes a network layoutmodule 502 that can be similar to network layout module 402 of system400. System 500 can also include a first cloud 510 and a second cloud520, and can provide communication with a network 570. Entities 530, 532can be a device accessible by and/or associated with an organizationand/or a user. Communication between entity 530 and entity 532 can bevia network 570 and can include one or more data paths via cloud 510and/or cloud 520 and via one or more virtual machines (VM) (not shown)instantiated in cloud 510 and/or cloud 520. For example, communicationbetween entity 530 and entity 532 via network 570 can routed through afirst VM in cloud 510, a first VM in cloud 520, a second VM in cloud510, a second VM in cloud 520, and then to entity 532 via network 570.Furthermore, as described herein, the data path between entity 530 andentity 532 can dynamically change on a schedule, randomly,pseudo-randomly, upon detection of a threat, by an administrator ofsystem 500, etc. In this manner, an attempt to identify the sourcelocation of a data transmitter along an initial path may be preventedbecause a new path has been subsequently established within system 500.In such embodiments, network layout module 502 can facilitate theupdating and distribution of routing tables within system 500. In oneexample, entity 532 can include a device associated with an employee toaccess data stored remotely relative to that device, and entity 530 caninclude a device storing the data. In such an example, system 500 candefine a secure virtual private network 501 between entity 532 andentity 530.

FIG. 6 depicts a schematic diagram of a physical layout for anidentity-protection system (“system”) 600 according to an embodiment. Asshown in FIG. 6 , system 600 can be used to define one or more securestorage and/or process networks 601 accessible by an entity 630. System600 can be similar to system 400 and can include similar components, forexample, system 600 can include a network layout module 602 that can besimilar to network layout module 402 of system 400. System 600 can alsoinclude a first cloud 610, a second cloud 620, a network 632, a networkelement 611, a network element 621, and a network element 631. In someembodiments network 632 can be an existing network for an organizationand/or user. In some embodiments, a network element can include astorage location and/or program/process location.

Communication between entity 630 and any of network elements 611, 621,631 of network 601 can include one or more data paths via cloud 610,cloud 620 and/or network 632 and via one or more virtual machines (VM)(not shown) instantiated in cloud 610, cloud 620 and/or network 632. Forexample, communication between entity 630 and any of network elements611, 621, 631 can be routed through a first VM in cloud 610, a first VMin cloud 620, a second VM in cloud 610, a second VM in cloud 620, andthen to any of network elements 611, 621, 631. Furthermore, as describedherein, the data path between entity 630 and any of network elements611, 621, 631 can dynamically change on a schedule, randomly,pseudo-randomly, upon detection of a threat, by an administrator ofsystem 600, etc.

In some embodiments, the locations of network elements 611, 621, 631and/or data paths between any of network elements 611, 621, 631 can bedynamically changed. For example, as shown in FIG. 6 , network element611 is associated with first cloud 610, network element 621 isassociated with second cloud 620 and network element 631 is associatedwith network 632. In such an embodiment, by way of example, networkelement 611, specifically the data (program, process, stored data, etc)can be moved, e.g. instantiated, in second cloud 620.

As described above, an attempt to identify the source location of a datatransmitter and/or a network element along an initial path may beprevented because a new path has been established within system 600. Insuch an example, entity 630 can access data stored at network entity621. In the event that the data path between entity 630 and networkelement 621 is compromised and/or if unauthorized to access networkentity 621 is attempted, either the data path can have changed, and orthe location of network entity 621 can have changed. In suchembodiments, network layout module 602, can facilitate the updating anddistribution of routing tables within system 600.

FIG. 7 depicts a schematic diagram of a physical layout for anidentity-protection system (“system”) 700 according to an embodiment. Asshown in FIG. 7 , system 700 can be used to define one or more securecustomer networks 701 accessible by an entity 730. In some embodiments,system 701 can be isolated from wide area networks, for example theinternet, and/or any other network. System 700 can be similar to system400 and can include similar components, for example, system 700 includesa network layout module 702 that can be similar to network layout module402 of system 400. System 700 can also include a first cloud 710, anetwork 732, a second cloud 720, a network element 711, a networkelement 721, and a network element 731. In some embodiments, a networkelement can include a storage location and/or process location.

Communication between entity 730 and any of network elements 711, 721,731 of network 701, and between any of any of network elements 711, 721,731 and any of another network elements 711, 721, 731 can include one ormore data paths via cloud 710 and/or cloud 720, network 732 and via oneor more virtual machines (VM) (not shown) instantiated in cloud 710and/or cloud 720, network 732. For example, communication between entity730 and any of network elements 711, 721, 731 can be routed through afirst VM in cloud 710, a first VM in cloud 720, a second VM in cloud710, a second VM in cloud 720, and then to any of network elements 711,721, 731 of network 701. Furthermore, as described herein, the data pathbetween entity 730 and any of network elements 711, 721, 731, candynamically change on a schedule, randomly, pseudo-randomly, upondetection of a threat, by an administrator of system 700, etc.

In some embodiments, the locations of network elements 711, 721, 731and/or data paths between any of network elements 711, 721, 731 can bedynamically changed. For example, as shown in FIG. 6 , network element711 is associated with first cloud 710, network element 721 isassociated with second cloud 720 and network element 731 is associatedwith network 732. In such an embodiment, by way of example, networkelement 711, specifically the data (program, process, stored data, etc)can be moved, e.g. instantiated, in second cloud 620.

As described above, entity 730 can access data stored or use a programand/or other process located at network entity 721. In the event thatthe data path between entity 730 and network element 721 is compromisedand/or if unauthorized access to network entity 721 is attempted, eitherthe data path can change, and or the location of network entity 721 canchange. In such embodiments, network layout module 702 can facilitatethe updating and distribution of routing tables within system 700.

FIG. 8 depicts a flow chart for defining an identity-protection system(“system”) according to some embodiments described herein. As shown inFIG. 8 , method 800 can be a loop to dynamically update the system. Themethod 800 includes that one or more exposing a set of attachments 822that are located on an OVS device, at 802. In some embodiments,operation 802 can be implemented in one or more transport nodes, forexample, transport node 820. The method 800 includes describing thesources and sinks of logical port 824 traffic, at 804. In someembodiments, operation 804 can be implemented in association with one ormore attachments, for example, VifAttachment/ExtNetAttachment 822. Themethod 800 includes defining service model for the set of logical ports824, at 806. In some embodiments, operation 806 can be implemented inone or more logical ports, for example, logical port 824. The method 800includes specifying one or more transport zones and/or encapsulationtypes to be used for forwarding traffic, at 808. In some embodiments,operation 808 can be implemented in one or more logical switches; forexample, logical switch 826, and a transport zone 828 can be specified.The method 800 includes grouping one or more transport connectorsaccording to zones of physical network connectivity, at 810. In someembodiments, operation 810 can include grouping, for example, transportconnector 830. The method 800 includes describing the connectivity thata transport node can use for a particular encapsulation type, at 812. Insome embodiments, operation 812 can be implemented in one or moretransport connector, for example, transport connector 830, and caninclude describing the connectivity, for example, of transport node 820.

FIG. 9 is a flow chart illustrating a method 900 of operating anidentity protection system according to an embodiment. Method 900includes defining, at a first time, a first data unit path from a sourcedevice to a destination device, at 902. The first data unit pathincludes (1) a first virtual machine and a second virtual machine thatare included in a first network, and (2) a third virtual machine that isincluded in a second network. The first data unit path further includesthe first virtual machine, the second virtual machine, and the thirdvirtual machine in a first order. Method 900 includes modifying, inresponse to defining the first data unit path, a routing table such thata first data unit sent from the source device to the destination device,prior to a second time after the first time, follows the first data unitpath, at 904. Method 900 includes defining, after the second time, asecond data unit path from the source device to the destination device,at 906. The second data unit path includes each of the first virtualmachine, the second virtual machine, and the third virtual machine in asecond order different from the first order. The method 900 includesmodifying, in response to defining the second data unit path, therouting table such that a second data unit sent from the source deviceto the destination device, after the second time, follows the seconddata unit path, at 908.

While shown and/or described herein as including a number of cloudnetwork, other networks, network elements, entities, etc, in someembodiments, there can be more or fewer network, elements and/orentities. For example, while system 600 is shown as including clouds710, 720 and network elements 711, 721, 731, in other instances system600 can include more or fewer clouds and/or network elements.

While the networks (e.g., local and legacy network, wide area network,clouds, etc) are shown and described herein in various logical and/orphysical configurations, in some embodiments, the networks can includedifferent configuration. For example, while FIG. 4 depicts first cloud410, second cloud 420 as overlapping, in some embodiments, first cloud410 and second cloud 420 can be mutually exclusive, logically and/orphysically. Similarly, while FIG. 6 depicts first cloud 610, secondcloud 620 and network 632 as mutually exclusive, in some embodiments,any of first cloud 610, second cloud 620 and network 632 can belogically and/or physically overlapping and/or mutually exclusive withany other of first cloud 610, second cloud 620 and network 632.

Some embodiments described herein relate to devices (e.g., wirelessaccess points, mobile communication devices) with a non-transitorycomputer-readable medium (also can be referred to as a non-transitoryprocessor-readable medium or memory) having instructions or computercode thereon for performing various computer-implemented operations. Thecomputer-readable medium (or processor-readable medium) isnon-transitory in the sense that it does not include transitorypropagating signals per se (e.g., a propagating electromagnetic wavecarrying information on a transmission medium such as space or a cable).The media and computer code (also can be referred to as code) may bethose designed and constructed for the specific purpose or purposes.Examples of non-transitory computer-readable media include, but are notlimited to: magnetic storage media such as hard disks, floppy disks, andmagnetic tape; optical storage media such as Compact Disc/Digital VideoDiscs (CD/DVDs), Compact Disc-Read Only Memories (CD-ROMs), andholographic devices; magneto-optical storage media such as opticaldisks; carrier wave signal processing modules; and hardware devices thatare specially configured to store and execute program code, such asApplication-Specific Integrated Circuits (ASICs), Programmable LogicDevices (PLDs), Read-Only Memory (ROM) and Random-Access Memory (RAM)devices. Other embodiments described herein relate to a computer programproduct, which can include, for example, the instructions and/orcomputer code discussed herein.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. Where methods and steps described above indicate certainevents occurring in certain order, the ordering of certain steps may bemodified. Additionally, certain of the steps may be performedconcurrently in a parallel process when possible, as well as performedsequentially as described above. Although various embodiments have beendescribed as having particular features and/or combinations ofcomponents, other embodiments are possible having any combination orsub-combination of any features and/or components from any of theembodiments described herein.

What is claimed is:
 1. An apparatus, comprising: a network layout moduleconfigured to be operatively coupled to (1) a first network thatincludes a first virtual machine and a second virtual machine, and thatis configured to be operatively coupled to a source device and adestination device; and (2) a second network, different from the firstnetwork, that includes a third virtual machine and a fourth virtualmachine, and that is configured to be operatively coupled to the sourcedevice and the destination device, the network layout module configuredto define, at a first time, a first data unit path from the sourcedevice to the destination device, the first data unit path includingeach of the first virtual machine, the second virtual machine, the thirdvirtual machine and the fourth virtual machine, the network layoutmodule configured define, at a second time after the first time, and inresponse to an event, a second data unit path from the source device tothe destination device, the second data unit path traversing the firstnetwork and the second network and differing from the first data unitpath.